Aller au contenu

Inspection de produit logiciel

Un article de Wikipédia, l'encyclopédie libre.
Inspection de produit logiciel

Le terme produit logiciel inclut un produit fini (un programme exécutable), mais également tout ce qui permet de développer ce produit[1].

L'inspection de produit logiciel[2] peut s'appliquer à n'importe quel produit, lisible par un humain. Il peut s'agir des spécifications d'un logiciel, des documents de conception, des tests, du code source...

Les inspections sont considérées comme l'un des outils les plus efficaces pour augmenter la qualité des logiciels produits. Avec un taux d'élimination des anomalies de 80 % à 95 %, contre 30 % pour les tests, c'est très efficace. L'utilisation d'un modérateur et d'un processus bien établi permet de limiter le temps requis pour ce type de revue et d'en augmenter la productivité. Il s'agit d'un outil remarquable de transfert d'expertise.

Toute revue n'est pas une inspection !

Le processus d'une inspection :

  1. L'auteur demande une inspection à un responsable d'inspection (modérateur)
  2. Le responsable détermine la liste des inspecteurs et convoque ceux-ci et l'auteur à une réunion de démarrage d'inspection
  3. L'auteur présente sommairement son produit
  4. Le responsable d'inspection présente les objectifs de l'inspection et assigne les rôles d'inspection
  5. Chaque inspecteur, dans les jours qui suivent, effectuera une lecture attentive du bien, en notant les anomalies. Cette étape est la plus importante, mais la moins documentée par la littérature sur les inspections et revues
  6. Une réunion d'inspection est tenue, dirigée par le responsable d'inspection, qui joue également le rôle de modérateur (garder le focus sur la détection des anomalies et désamorcer les conflits)
  7. Un lecteur présente le produit, par petites sections, en reformulant. Cette reformulation augmente les chances de détecter les ambiguïtés.
  8. Les inspecteurs indiquent les anomalies qu'ils ont détectées
  9. Les seules discussions admises, portent sur la compréhension des anomalies, pas sur les solutions ou sur la pertinence d'une anomalie.
  10. Un scribe enregistre les anomalies
  11. Une fiche d'inspection est remplie
  12. L'auteur corrige ou justifie chaque anomalie
  13. Le responsable de l'inspection s'assure que l'ensemble des anomalies ont été traitées
  14. Le responsable de l'inspection indique si le produit a passé l'inspection ou pas.


C'est très formel, mais la mise en commun des résultats d'inspection permet rapidement d'augmenter l'expertise d'inspection des inspecteurs. De plus, l'auteur ne peut biaiser les résultats d'inspection. La garantie de l'administration de ne pas utiliser les résultats des inspections pour évaluer les auteurs, a un impact important sur l'adhésion des personnes au processus d'inspection et sur le nombre d'anomalies détectées.

Par la suite, les inspecteurs ayant effectué au moins 3 inspections, sont généralement d'excellents réviseurs, même quand le formalisme est moins grand. Il y a un changement de culture individuelle.

Notes et références

[modifier | modifier le code]
  1. (fr) « Inspection de logiciel », sur www.worldlingo.com (consulté le )
  2. (fr) « Définition », sur www.techap.com (consulté le )

Articles connexes

[modifier | modifier le code]